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(54) Title: METHOD FOR CONVERTING A SYSTEM CALL 

(54) Bezeichnung: VERFAHREN ZUM UMSETZEN EINES SYSTEM AUFRUFS 

(57) Abstract 

The invention relates to a method for converting a system call for an original operating 
system into a system call (20) for a target operating system (14). According to said method an 
emulation routine (16) is called up, converts a reference structure having a reference value and at 
least one referenced element by converting at least the reference value, and executes the system 
call (20) for the target operating system (14). This method makes it possible to run application 
programs (12) on a target operating system (10) without special adaptation or reconversion even 
if the original operating system was not transferred to the target system (10). 

(57) Zusammenfassung 

Bei einem Verfahren zum Umsetzen eines Systemaufrufs fur ein Ursprungs-Betriebssystem 
in einen Systemaufruf (20) fiir ein Ziel-Betriebssystem (14) wird eine Emulationsroutine (16) 
aufgerufen. Die Emulationsroutine (16) setzt eine Referenzstruktur, die einen Refcrenzwert 
und zumindest ein referenziertes Element aufweist, urn, indem zumindest der Referenzwert 
umgesetzt wird, und sie fOhrt den Systemaufruf (20) far das Ziel-Betriebssystem (14) durch. 
Dieses Verfahren ermoglicht es, Anwendungsprogramme (12) ohne spezielle Anpassung oder 
Neuuberseizung auf einem Zielsystem (10) ablaufen zu lassen, auch wenn das ursprunghche 
Betriebssystem nicht auf das Zielsystem (10) portiert wurde. 
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Verfahren zum Umsetzen eines Systemauf ruf s 

Die Erfindung betrifft ein Verfahren zum Umsetzen eines Sy- 
stemaufrufs fur ein Ursprungs-Betriebssystem in einen System- 
aufruf fur ein Ziel-Betriebssystem. 

Die Erfindung ist insbesondere dann einsetzbar, -wenn ein An- 
wendungsprogramm, das fur ein urspriingliches System (Prozes- 
sor und Betriebssystem) erstellt wurde, auf einem anderen 
Zielsystem ablaufen soli. Besonders ist die Erfindung fur den 
Fall vorgesehen, dafl das Ursprungs- und das Ziel-Betriebssy- 
stem zwar miteinander verwandt sind, sich aber dennoch etwas 
voneinander unterscheiden . Beispielsweise kann es sich bei 
den beiden Betriebssystemen urn verschiedene UNIX-Varianten 
oder urn Portierungen eines Betriebssystems auf unterschied- 
liche Hardware handeln. So konnen etwa die folgenden Abwei- 
chungen der Hardwarearchitektur Auswirkungen auf die Schnitt- 
stelle zwischen dem Anwendungsprogramm und dem Betriebssystem 
haben : 

unterschiedliche Adrefibereiche und/oder Adreilraumtopolo- 
gien (z.B. Obergang von einem 32-Bit- auf ein 64-Bit- 
System) , 

unterschiedliche Reihenfolge der Bytes binarer numeri- 
scher Werte im Speicher (z.B. Obergang von einem Little- 
Endian- auf ein Big-Endian-System) , und 
unterschiedliche Codierung von Zeichen (z.B. Obergang 
von einem ASCII- auf ein EBCDIC-System) . 

Es ist eine bekannte Vorgehensweise, bei einem Umstieg auf 
eine andere Prozessorarchitektur auch das ursprungliche Be- 
triebssystem auf den Zielprozessor zu portieren. Gegebenen- 
falls vorgesehene Erweiterungen des Betriebssystems werden in 
diesem Fall in einer Weise durchgefiihrt, die die bisherige 
Funktionalitat unverandert lafit (Abwartskompatibilitat ) . Zum 
Ausfiihren der Anwendungsprogramme dienen an sich bekannte 
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Verfahren, beispielsweise Emulation oder statische oder dyna- 
mische Ob j ektkode-Transf ormation . Die in den Anwendungspro- 
grammen enthaltenen Systemaufrufe brauchen dabei nicht geson- 
dert beriicksichtigt zu werden, weil sie auch auf dem portier- 
ten Betriebssystem gultig sind. 

Die bei diesem Verfahren erf order liche Portierung des Be- 
triebssystems auf den Zielrechner ist jedoch aufwendig. Um 
die Abwartskompatibilitat zu erhalten, mtissen oft technische 
Kompromisse eingegangen werden, die die Leistungsf ahigkeit 
des neuen Betriebssystems beeintrachtigen. 

Aus dem US-Patent 5,313,614 ist es bekannt, sowohl ein Anwen 
dungsprogramm als auch ein ursprlingliches Betriebssystem auf 
die neue Rechenanlage zu portieren, die ihrerseits ein eigen 
standiges Betriebssystem aufweist. In diesem Fall konnen die 
Systemaufrufe des Anwendungsprogramms unverandert beibehalte 
werden. Das Verfahren ist jedoch wegen der er f orderlichen 
Portierung relativ aufwendig. 

Es ist demgemafi die Aufgabe der Erfindung, die genannten Pro 
bleme zu vermeiden und ein Verfahren zum Umsetzen eines Sy- 
sternaufrufs bereitzustellen, das keine Portierung des ur- 
sprunglichen Betriebssystems erfordert und dennoch ermog- 
licht, ein Anwendungsprogramm ohne spezielle Anpassung oder 
Neuubersetzung auf dem Zielsystem ablaufen zu lassen. Dies 
ist insbesondere dann wichtig, wenn das Anwendungsprogramm 
nur als Objektkode vorliegt. 

Erf indungsgemaJJ wird diese Aufgabe durch ein Verfahren mit 
den Merkmalen des Anspruchs 1 gelost. Die Aufzahlung der 
Merkmale in Anspruch 1 soil keine Reihenfolge der Schritte 
bei der Ausfuhrung des beanspruchten Verfahrens bedeuten; 
insbesondere kann das Umsetzen der Ref erenzstruktur sowohl 
einen Parameter fur den Systemaufruf als auch einen Ergebni 
wert des Systemaufruf s betreffen. Der Begriff "Systemaufruf 
soil hier den gesamten mit dem Aufruf eines Betriebssystem- 
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dienstes zusammenhangenden Vorgang (einschlielilich der Riick- 
gabe des Ergebnisses) umfassen. 

Die Erfindung geht von der Grundidee aus, Systemauf ruf e 
(system calls, supervisor calls) des Anwendungsprogramms an 
das urspriingliche Betriebssystem durch spezielle Emulations- 
routinen abzufangen und in Aufrufe an das Ziel-Betriebssystem 
umzusetzen. Dabei ist es fur die Erfindung wesentlich, geeig- 
nete Umset zverf ahren fiir Ref erenzstrukturen bereit zus t ellen . 
Als Referenzstrukturen sollen hierbei Strukturen bezeichnet 
werden, die nicht nur die eigentlichen Daten beinhalten, son- 
dern einen Referenzwert aufweisen, mittels dessen ein Zugriff 
auf referenzierte Elemente (Daten, Funktionen, private Berei- 
che des Betriebssystems, . ..) moglich ist. In vielen Fallen 
wird bei Prozedur- oder Systemauf ruf en nur der Referenzwert 
iibergeben, beispielsweise ein Zeiger (pointer) oder ein Index 
oder ein Bezeichner. Der Begriff "Struktur" ist im hier ver- 
wendeten Sprachgebrauch im weitesten Sinne als jede Anordnung 
von Daten und/oder Referenzen zu verstehen und soil insbeson- 
dere nicht auf den Datentyp einer "structure" in der Program- 
miersprache C beschrankt sein. 

Die Erfindung bietet die Moglichkeit, Anwendungsprogramme auf 
neuen und weiterentwickelten Systemen auszuftihren. Wenn die 
Maschinensprachen des ursprunglichen und des neuen Systems 
ubereinstimmen (Binarcode-Kompatibilitat ) , kann das Anwen- 
dungsprogramm unverandert oder mit minimalen Modif ikationen 
auf dem Zielsystem ablaufen. Andernfalls muB mit an sich be- 
kannten Verfahren fUr eine geeignete Umsetzung gesorgt wer- 
den. Beispielsweise kann ein Emulator fiir die Maschinenspra- 
che des Anwendungsprogramms bereitgestellt werden, oder es 
konnen Techniken der statischen oder dynamischen Objektkode- 
Transformation eingesetzt werden. Bei alien diesen Techniken 
kann die Erfindung verwendet werden, um fur eine Umsetzung 
von Systemauf ruf en zu sorgen. 
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Neben der Anwendung bei der Migration von Anwendungsprogram- 
men kann die Erfindung auch eingesetzt werden, wenn eine 
Client/Server-Architektur aus nicht aufeinander abgestimmten 
Client- und Server-Komponenten aufgebaut werden soil. In die- 
sem Fall wird das er f indungsgemaile Verfahren von einem Adap- 
ter ausgefiihrt, der zwischen Client und Server geschaltet ist 
oder der den Server im Sinne einer Zwischenschicht umgibt 
(wrapping) . Ferner kann das erf indungsgemafie Verfahren auch 
von Adaptern ausgefiihrt werden, die automatisch aus einer 
IDL-Schnittstellenbeschreibung (IDL = interface definition 
language) generiert worden sind. Allgemein ist die Erfindung 
immer dann einsetzbar, wenn Systemauf ruf e mit Ref erenzstruk- 
turen auftreten konnen. Dabei kann es sich um Aufrufe eines 
(lokalen) Anwendungsprogramms oder um nicht-lokale Aufrufe 
(remote procedure call oder remote system call) handeln. 

In bevorzugten Ausf iihrungsf ormen der Erfindung fuhren die 
Emulationsroutinen zumindest uberwiegend Umsetzungsf unktionen 
(im Gegensatz zu Betriebssystemf unktionen) aus. Vorzugsweise 
betragt der Anteil der Umsetzungsf unktionen uber 70 % oder 
uber 90 %, und der Anteil anderer Funktionen ist nur gering. 
Dadurch wird die wesentliche Arbeit vom Ziel-Betriebssystem 
geleistet- Die Emulationsroutinen konnen dann relativ kompakt 
gehalten werden und sind weit weniger aufwendig in der Ent- 
wicklung, als es die Portierung eines Betriebssystems ware. 

In bevorzugten Ausf iihrungsf ormen wird, falls dies erforder- 
lich ist, nicht nur der Ref erenzwert , sondern auch das minde- 
stens eine ref erenzierte Element zumindest teilweise umge- 
setzt. Es kann sich bei dem ref erenzier ten Element jedoch 
auch um ein nicht weiter interpretierbares Element handeln. 
Beispielsweise kann es ein Element eines abstrakten Datentyps 
sein. In diesem Fall ist bevorzugt eine Umsetztabelle vorge- 
sehen, um Ref erenzwerte gemali den Konventionen des Ursprungs- 
und des Ziel-Betriebssystems einander zuzuordnen. Die Umsetz- 
tabelle kann durch beliebige Mittel implement iert werden, di< 
diese Zuordnungsf unktionalitat bereitstellen . 
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In weiteren bevorzugten Ausf uhrungsf ormen kann das referen- 
zierte Element eine Funktion sein. Die Emulat ionsroutine 
ersetzt dann bevorzugt den ursprunglichen -Ref erenzwert durch 
einen neuen Ref erenzwert , der auf eine Adapter funktion ver- 
weist. Die Adapterf unktion kann generisch sein oder bei der 
Umsetzung speziell in Abhangigkeit von dem Typ oder anderen 
Eigenschaften der urspriinglichen Funktion erzeugt werden. 
Auch hierbei kann die Verwendung einer Tabelle vorgesehen 



10 sein. 



In weiteren bevorzugten Ausfiihrungsf ormen ist das referen- 
zierte Element eine Systemdatei und/oder ein Tupel und/oder 
eine verkettete Datenstruktur und/oder ein Datum und/oder 
15 eine Zeitangabe und/oder ein Kontext und/oder ein Array 

und/oder eine Zeichenkette . In diesen und anderen Fallen kann 
das referenzierte Element eine von der Emulationsroutine 
interpretierbare Bedeutung haben. Die Umsetzung erfolgt dann 
so, dafi diese Bedeutung moglichst weitgehend erhalten wird. 



30 



Weitere bevorzugte Ausf uhrungsf ormen sind Gegenstand der 
Unteranspruche . 

Ausfuhrungsbeispiele der Erfindung werden nun unter Hinweis 
auf die Zeichnungen genauer beschrieben. Es zeigen: 

Fig. 1 eine schematische Darstellung der prinzipiellen Ein- 
bindung des erf indungsgemafcen Umsetzverf ahrens in die Pro- 
grammausf uhrung, 

Fig. 2 eine schematische Darstellung der Einbettung eines 
Adrefiraumes eines Ursprungssystems in einen AdreBraum eines 
Zielsystems, 



35 Fig. 3 eine schematische Darstellung der Umsetzung eines 
Tupels, 
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Fig. 4 eine schemat ische Darstellung der Umsetzung eines 
abstrakten Datentyps, 

Fig. 5 eine schematische Darstellung der Umsetzung eines 
Funktionsparameters mit dynamischer Generierung einer 
Adapterfunktion, und 

Fig. 6 eine schematische Darstellung der Umsetzung eines 
Funktionsparameters unter Verwendung einer universellen 
Adapterf unktion . 

In der Darstellung von Fig. 1 fiihrt ein Zielsystem 10 ein An- 
wendungsprogramm 12 aus . Das Zielsystem 10 beinhaltet ein 
Ziel-Betriebssystem 14, das eine Vielzahl von Systemauf ruf en 
zu bearbeiten vermag. Das Anwendungsprogramin 12 ist fur ein 
Ursprungs-Betriebssystem vorgesehen, das sich von dem Ziel- 
Betriebssystem 14 etwas unterscheidet . Demzufolge sind die im 
Anwendungsprogramm 12 enthaltenen Systemauf ruf e nicht voll- 
standig mit den vom Ziel-Betriebssystem 14 bereitgestellten 
Systemdiensten kompatibel. Selbst wenn die Funktionen der 
einzelnen Systemauf ruf e ungefahr iibereinstimmen, unterschei- 
den sich in der Regel die Art der Parameter- und Ergebnis- 
ubergabe sowie die Datentypen der Parameter und Ergebnisse 
(Wertebereiche und Kodierung der Werte) . 

Um dennoch das Anwendungsprogramm 12 auf dem Zielsystem 10 
ausfiihren zu konnen, ohne dafi ersteres umgeschrieben werden 
mufi, sind mehrere Emulationsroutinen vorgesehen, von denen in 
Fig. 1 eine mit dem Bezugszeichen 16 gezeigt ist. Die Emula- 
tionsroutinen sind " zwischen" das Anwendungsprogramm 12 und 
das Ziel-Betriebssystem 14 geschaltet. Wenn das Anwendungs- 
programm 12 einen Systemauf ruf durchftihrt, der den Konventio- 
nen des Ursprungs-Betriebssystems entspricht, wird dieser in 
einen Auf ruf 18 der Emulationsroutine 16 umgesetzt. Die Emu- 
lationsroutine 16 sorgt ihrerseits fur die notwendigen Kon- 
vertierungen der Parameter und fiihrt dann mindestens einen an 
das Ziel-Betriebssystem 14 gerichteten Systemaufruf 20 aus. 
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Ergebniswerte, die das Ziel-Betriebssystem 14 gegebenenf alls 
zuruckgibt, werden wiederum von der Emulations routine 16 kon- 
vertiert und an das Anwendungsprogramm 12 weitergeleitet . Die 
Einzelheiten der Umwandlung unterschiedlicher Datentypen wer- 
den unten genauer erlautert. 

Bei dem in Fig. 1 gezeigten Beispiel ist der Ablaufkode (Ma- 
schinenbefehlssatz) des Zielsystems 10 binarkompatibel mit 
dem des Ursprungssystems. Das Anwendungsprogramm 12 kann da- 
her unmittelbar vom Zielsystem 10 ausgefiihrt werden. Die Emu- 
lationsroutinen 16 sind dadurch in die Aufrufkette eingebun- 
den, daft entsprechende Handler fur Systemauf ruf e beim Ziel- 
Betriebssystem 14 eingetragen sind. 

In Ausfuhrungsalternativen, bei denen das Anwendungsprogramm 
12 nicht unmittelbar auf dem Zielsystem 10 lauffahig ist, ist 
ein geeigneter Emulator oder Obj ektkode-Trans f ormator vorge- 
sehen, der den Binarkode des Anwendungsprogramms 12 statisch 
oder dynamisch umsetzt und dabei auch die im Anwendungspro- 
gramm 12 enthaltenen Systemauf ruf e geeignet abfangt oder 
transf ormiert . 

Bei der folgenden Beschreibung der Umwandlung unterschiedli- 
cher Datentypen durch die Emulationsroutinen 16 wird ein den 
Konventionen des Ursprungs-Betriebssystems entsprechender Da- 
tentyp als Ursprungstyp und der zugeordnete Datentyp des 
Ziel-Betriebssystems 14 als Zieltyp bezeichnet. Auch die Be- 
handlung von Datentypen, die keine Ref erenztypen sind, wird 
der Vollstandigkeit halber kurz dargestellt. Im Idealfall 
soli durch die Umwandlung eine eineindeutige Abbildung der 
Werte des Ursprungstyps in Werte des Zieltyps und umgekehrt 
gefunden werden. 

1. Einfache Typen 



1.1 Numerische Typen 
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Hierbei werden die liblichen Konvertierungsregeln verwendet, 
wie sie beispielsweise von hoheren Programmiersprachen be- 
kannt sind. Daruber hinaus werden Unterschiede zwischen dem 
Ursprungssystem und dem Zielsystem 10 hinsichtlich der Kodie- 
rung numerischer Werte beriicksichtigt . Beispielsweise konnen 
sich die beiden Systeme hinsichtlich der Art der Gleitkomma- 
darstellungen oder der Zahlenkodierung (dezimal versus binar, 
big-endian versus little-endian) unterscheiden . 

Falls der Wertebereich eines Datentyps in einem System grofier 
ist als in dem anderen, konnen bei der Konvert ierung Werte 
auflerhalb des zulassigen Bereichs auftreten. Die Emulations- 
routinen 16 losen bei solchen unzulassigen Werten eine Aus- 
nahme (exception) aus . 

1.2 Zeichentypen 

Zeichentypen werden analog zu numerischen Typen behandelt, 
wobei unterschiedliche Zeichenkodierungen im Ursprungs- und 
Zielsystem zu berucksichtigen sind (siehe auch Abschnitt 
2.4) . 

1 . 3 Auf zahlungstypen 

Auf zahlungstypen (zum Beispiel der UNIX-Typ "idop_t") werden 
im allgemeinen wie numerische Typen umgesetzt. Dies gilt je- 
doch dann nicht, wenn die Werte eines Auf zahlungstyps eine 
Bedeutung haben, die Betriebssystemf unktionen betrifft. Bei- 
spielsweise werden Auf zahlungstypen oft als Funktionskode zur 
Bestimmung einer Unterf unktion eines Sys temauf ruf s oder als 
Fehlerkode zur Ruckmeldung einer Ausnahmesituation verwendet. 
In diesen Fallen behandeln manche Ausf uhrungsf ormen der Er- 
findung ein Element eines Auf zahlungstyps als Ref erenzstruk- 
tur, die eine bestimmte Betriebssystemf unktion oder ein be- 
stimmtes Ergebnis ref erenziert . Die Umsetzung erfolgt dann 
so, dafi die Bedeutung des Elements des Auf zahlungstyps mog- 
lichst weitgehend erhalten bleibt. 
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Wenn der Auf zahlungstyp zum Beispiel Funktionskodes enthalt, 
fuhrt die Emulationsroutine 16 denjenigen Systemaufruf des 
Ziel-BetrJ.ebssystems 14 aus, der die gewiinschte Funktionali- 
tat bereitstellt . Je nach den Umstanden des Einzelfalls kann 
dabei entweder ein anderer Systemaufruf oder ein anderer 
Funktionskode verwendet werden. Entsprechend wird ein von dem 
Ziel-Betriebssystem 20 zuriickgegebener Fehlerkode bestmoglich 
auf einen Fehlerkode des Ursprungs-Betriebssystems abgebil- 
det. Je nachdem, welches Betriebssystem eine feinere Auffa- 
cherung der Fehlerkodes bereitstellt, wird dazu entweder ein 
zusammenfassender Kode des Ursprungs-Betriebssystems fur meh- 
rere Kodes des Ziel-Betriebssystems 20 erzeugt, oder es wer- 
den nur einige der Fehlerkodes des Ursprungs-Betriebssystems, 
namlich die jeweils am besten treffenden, verwendet. 

1.4 Zeigertypen (Pointer, Adressen) 

Zur Umsetzung von Zeigertypen mull eine Abbildung zwischen den 
Adrefiraumen des Ursprungs- und des Zielsystems gewahlt und 
bei der Parameter- und Ergebnisubergabe angewendet werden. 

Fig. 2 zeigt ein Beispiel, bei dem ein Adrefiraum 22 (von An- 
wendungsprogrammen benutzbarer Adrelibereich) des Ursprungs- 
5 systems kleiner als ein Adrefiraum 24 des Zielsystems 10 ist. 
Der Adrefiraum 22 wird in diesem Fall in den Adrefiraum 24 ein- 
gebettet, wie dies durch die gestrichelten Linien in Fig. 2 
angedeutet ist. Bei der Einbettung ist jedoch darauf zu ach- 
ten, dafi Systemaufruf e 20 fur das Ziel-Betriebssystem 14 als 
0 Ergebnisse nur Zeigerwerte liefern, die innerhalb des Adrefi- 
raumes 24 in den Bereich des eingebetteten urspriinglichen 
Adrefiraumes 22 zeigen. Beispielsweise kann es erforderlich 
sein, den auf dem Ursprungssystem reservierten Adrelibereich 
fur gemeinsamen Bibliothekskode (shared library code) auf 
5 einen Bereich abzubilden, der auch im Zielsystem 10 hierfur 
reserviert ist. Gegebenenf alls mufi dabei der ursprungliche 
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Adreliraum 22 in mehreren getrennten Bereichen 26, 28 in den 
Adreliraum 24 des Zielsystems 10 eingebettet werden. 

Wenn dagegen der Ziel-Adrefiraum 24 kleiner als der ursprung- 
liche Adreliraum 22 ist, sind nur solche Anwendungsprogramme 
12 auf dem Zielsystem 10 lauffahig, die nicht den vollen ur- 
spriinglichen Adreliraum 22 ausnutzen. In diesem Fall kann nur 
fur einen Teil der ursprungl ichen Adressen eine eindeutige 
Abbildung in den Ziel -Adrefiraum 24 definiert werden. Falls 
beim Programmablauf Zeigerwerte oder Adressen auiierhalb des 
definierten Teils des ur sprunglichen Adrefiraumes liegen und 
bei einem Systemaufruf tibergeben werden sollen, lost die je- 
weils betroffene Emulat ionsroutine 16 eine ent sprechende 
Ausnahme (exception) aus. 

In vielen Fallen zeigt ein Element eines Zeigertyps auf eine 
nicht naher spezif izierte Datenstruktur , die nicht weiter 
interpretiert werden mufi . In der Notation der Sprache C wird 
dies durch die Typangabe "void*" ausgedruckt. Wenn dies nicht 
der Fall ist, muft gegebenenf alls neben dem gerade beschriebe- 
nen Umsetzen des Zeigerwertes auch die ref erenzierte Daten- 
struktur konvertiert werden. Beispiele dafur werden unten in 
den Abschnitten 2.1, 2.2, 2.3, 2.4 und 2.5 genauer behandelt. 
Hinsichtlich des weiteren Spezialfalls eines Zeigers auf eine 
Funktion wird auf Abschnitt 4 verwiesen. 

2. Zusammengesetzte Typen 

2.1 Produktdatentypen (Tupel) 

Der Aufbau von Produktdatentypen, die als Parameter oder Er- 
gebnis eines Systemaufruf s libergeben werden, ist durch das 
ursprungliche Betriebssystem vorgegeben und somit bekannt. 
Ein Produktdatentyp heilit in der Programmier sprache C 
"struct" oder "structure". Die Elemente eines Produktdaten- 
typs werden hier als Tupel bezeichnet, urn eine Verwechslung 
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mit dem Begriff einer Datenstruktur im weiteren Sinne zu 
vermeiden . 

Falls die Felder eines Tupels nur Datentypen enthalten, die 
keine Konvert ierung erfordern, braucht die Emulationsroutine 
16 lediglich einen Zeiger auf das Tupel gemaft dem in Ab- 
schnitt 1.4 beschriebenen Verfahren zu konvertieren und zu 
ubergeben . 

Wenn dagegen die Felder eines Tupels konvertiert werden miis- 
sen, dann kopiert die betroffene Emulat ions rout ine 16 bei 
einem Systemaufruf des Anwendungsprogramms 12 das komplette 
Tupel feldweise und ubergibt einen Zeiger auf die Kopie an 
das Ziel-Betriebssystem 14. Falls das Ziel-Betriebssystem 14 
das kopierte Tupel verandert, dann konvertiert die Emula- 
tionsroutine 16 die Anderungen wieder zuruck in das ursprung- 
liche Tupel. Ein Kopieren und Konvertieren des Tupels kann 
auch dann erforderlich sein, wenn das Layout (Anzahl, Reihen- 
folge und Ausrichtung der Felder) des Tupels im Ursprungssy- 
stem nicht den Konventionen im Zielsystem 10 entspricht . 



Fig. 3 zeigt beispielhaft einen Ausschnitt 30 aus dem in der 
Sprache C geschriebenen Anwendungsprogramm 12, in dem ein 
Tupel 32 definiert und ein den Konventionen des Ursprungs- 

5 systems entsprechender Systemaufruf durchgefuhrt wird. Dieser 
Aufruf wird von einem Ausschnitt 34 der Emulationsroutine 16 
verarbeitet, wie oben beschrieben. Die Emulationsroutine 16 
legt dazu ein konvertiertes Tupel 36 an, ruft das Ziel- 
Betriebssystem 14 auf und ubertragt eventuelle Anderungen 

0 zuruck in das Tupel 32. 



2.2 Datum und Zeit 



Datums- und Zeittypen sind meist numerische Werte Oder 
5 Tupel. Die Emulationsrout inen 16 wenden vorbestimmte Kon- 

vertierungsregeln an, um unterschiedliche Formate und Layouts 
ineinander umzuwandeln . Falls bei einem Datumstyp eine zwei- 
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stellige Jahreszahl in eine vierstellige Jahreszahl zu kon- 
vertieren ist, mtissen heur istische Verfahren angewandt 
werden . 

Bei Datentypen flir die Angabe von Zeitpunkten (zum Beispiel 
der UNIX-Typ "hrt ime_t " ) muft gegebenenf alls eine unterschied- 
liche Aufldsung oder Granularitat berucksichtigt werden. Ins- 
besondere miissen zwei im Ursprungstyp verschiedene Zeitstem- 
pel auch im Zieltyp verschieden sein. Falls die • Auf losung im 
Zieltyp geringer als im Ursprungstyp ist, verzogert die Emu- 
lationsroutine 16 gegebenenf alls den Systemauf ruf 20, urn ei- 
nen Zeitstempel zu erhalten, der auch in der Zeitauf losung 
des Ursprungstyps neu ist. 

2.3 Kontext 

Ein Kontexttyp bezeichnet ein Tupel, das den vollstandigen 
oder teilweisen Prozessorzustand (unter anderem Register- 
inhalte, Bef ehlszahler , ...) zu einem bestimmten Zeitpunkt 
(zum Beispiel zu einem Unterbrechungs zeitpunkt ) festhalt. 

Falls die Prozessorarchitektur des Ursprungssystems verschie- 
den von der des Zielsystems 10 ist, so unter scheiden sich die 
Kontexttupel im Regelfall erheblich. Damit das Anwendungspro- 
gramm 12 ohne Neuilbersetzung auf dem Zielsystem ablauffahig 
ist, wird entweder der ursprtingliche Prozessor auf dem Ziel- 
prozessor emuliert, oder das Anwendungsprogramm 12 wird auf 
Obj ektkodeebene dynamisch oder statisch transf ormiert . 

Bei einer Emulation verwaltet der Emulator den emulierten 
Kontext des ursprunglichen Prozessors. Jede Emulationsroutine 
16 fur einen Systemauf ruf , der einen Kontext verarbeiten 
und/oder als Ergebnis liefern soli, greift auf diesen emu- 
lierten Kontext zu und gibt ihn an das Anwendungsprogramm 12 
zuruck . 
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Falls die urspriingliche Applikation mittels einer statischen 
Oder dynamischen Objektkodetransf ormation in ein auf dem 
Zielsystem 10 lauffahiges Programm umgesetzt wird, muft diese 
Transformation ebenfalls dafiir sorgen, dafi an moglichen Un- 
terbrechungsstellen der Kontext gemafi den Gegebenhei ten des 
Ursprungsprozessors ermittelt werden kann . Dazu kann zura Bei- 
spiel bei einer asynchronen Unterbrechung das Anwendungspro- 
gramm 12 in einem Einzelschri ttmodus bis zu einem nachsten 
Synchronisationspunkt fortgefiihrt werden, an dem der Kontext 
des Ursprungsprozessors vollstandig zur Verfiigung steht. 

2.4 Arrays (Felder) und Zeichenketten 

Arrays werden analog zu den in Abschnitt 2.1 beschriebenen 
Produktdatentypen behandelt. Hierbei sind einige haufig vor- 
kommende Sonderfalle zu berucksichtigen . Dies gilt insbeson- 
dere fur Zeichenketten, die einen Spezialfall von Arrays dar- 
stellen . 

0 Bei der Konvertierung einer Zeichenkette miissen die einzelnen 
Zeichen umgesetzt werden, falls sie im Ursprungssystem anders 
als im Zielsystem 10 kodiert sind (zura Beispiel bei einer 
EBCDIC-Kodierung einerseits und einer ASCII-Kodierung ande- 
rerseits) . Selbst bei gleichem Zeichenkode kann eine Konver- 
5 tierung erforderlich sein, wenn sich die Speicherdars tellung 
einer Zeichenkette im urspriinglichen System und im Zielsystem 
10 unterscheidet . Beispielsweise kann in einem System die 
Konvention bestehen, eine Zeichenkette mit einem terminie- 
renden Zeichen abzuschlielben (wie in der Programmiersprache 
0 C), wahrend in dem anderen System die Lange der Zeichenkette 
in einem eigenen Langenfeld angegeben ist. In solchen Fallen 
erzeugt die betreffende Emulationsroutine 12 Kopien der Zei- 
chenketten in der jeweils anderen Darstellung. 

*S Ein weiterer Sonderfall bei der Behandlung von Zeichenketten 
tritt auf, wenn die Zeichenkette einen Pfad- und/oder Datei- 
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namen enthalt. Dieser Fall ist unten in Abschnitt 5 beschrie- 
ben . 

Schlieftlich ist noch der Fall zu berucksichtigen, dafi ein 
Systemdienst ( zum Beispiel der UNIX-Dienst "uname") Inf orma- 
tionen liber die Systemarchitektur und -version des Zielsy- 
stems 10 in Form einer Zeichenkette liefert. Das Anwendungs- 
programm 12 erwartet hi'er Inf ormationen uber das Ursprungssy- 
stem. Diese Inf ormationen werden von der betreffenden Emula- 
tionsroutine 16 entsprechend der emulierten Systemvers ion 
selbst generiert, ohne dafi der entsprechende Dienst des Ziel- 
Betriebssystems 14 in Anspruch genommen wird. Analog wird 
verfahren, wenn das Anwendungsprogramm 12 derartige Informa- 
tionen als Tupel erwartet. 

2.5 Verkettete Datenstrukturen 

Falls Datenstrukturen, insbesondere Tupel oder Arrays, ihrer- 
seits Referenzen auf andere Datenstrukturen enthalten, dann 
mussen gegebenenf alls auch diese ref erenzierten Datenstruktu- 
ren konvertiert werden. Die Emulationsroutinen 16 durchlaufen 
dabei die verkettete Datenstruktur und fuhren die erforderli- 
chen Kopier- und Umset zvorgange aus (tiefe Kopie - deep 
copy) . Die Konvertierung wird beendet, wenn entweder die ge- 
samte Datenstruktur durchlaufen wurde, oder wenn sicherge- 
stellt ist, dafi sich in den noch nicht bearbeiteten Abschnit- 
ten der Datenstruktur keine zu konvertierenden Daten befin- 
den. 

2.6 Reservierte Felder in Datenstrukturen 

Ein Parameter- oder Ergebnistyp kann eine Datenstruktur sein, 
die sowohl Felder enthalt, die von dem Anwendungsprogramm 12 
interpretiert werden, als auch Felder, die fur das System re- 
serviert sind (partiell abstrakter Datentyp) . In diesem Fall 
werden die reservierten Felder wie abstrakte Datentypen be- 
handelt, die im folgenden Abschnitt 3 beschrieben sind. Die 
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interpretierbaren Felder werden wie normale Datenstrukturen 
umgeset zt . 

3. Abstrakte Datentypen 

Das Ergebnis eines Systemauf ruf s 20 kann ein Wert (Handle, 
Index) sein, der zum Zugriff auf systeminterne Datenstruktu- 
ren dient, aber von dem Anwendungsprogramm 12 nicht weiter 
interpretiert werden kann und darf. Das Anwendungsprogramm 12 
kann nur den erhaltenen Wert als Referenzwert aufbewahren, um 
ihn spater einem anderen Systemauf ruf als Parameter zu iiber- 
aeben. Aus Sicht des Anwendungsprogramms 12 handelt es sich 
um einen abstrakten Datentyp, fur den das System Konstrukto- 
ren und Operationen in Form von Systemauf ruf en anbietet. Der 
abstrakte Datentyp ist identisch mit dem Typ der verwendeten 
Ref erenzwerte . Beispielsweise dienen fur den abstrakten Da- 
tentyp "Datei" File-Deskriptoren als Ref erenzwerte . Diese 
File-Deskriptoren sind in UNIX haufig mit dem numerischen 
Datentyp "int" deklariert. 

In vielen Fallen sind abstrakte Datentypen (das heifit, deren 
Ref erenzwerte) auf dem ursprunglichen System und auf dem 
Zielsystem 10 so unterschiedlich, daft sie verschieden viel 
Speicher belegen. Falls Grofie oder Ausrichtung des Ursprungs- 
typs nicht ausreichen, um alle moglichen Ref erenzwerte des 
Zieltyps aufzunehmen, dann verwalten die Emulat ionsrout inen 
16 eine Umsetztabelle, die jedem Referenzwert des Zieltyps 
einen Referenzwert des Ursprungstyps zuordnet. 

Dieses Verfahren ist beispielhaft in Fig. 4 gezeigt. Ein Aus- 
schnitt 38 des Anwendungsprogramms 12 enthalt zwei Systemauf- 
rufe, die von der Emulationsroutine 16 abgefangen werden. Die 
Emulationsroutine 16 fuhrt ihrerseits die in einem Ausschnitt 
40 gezeigten Systemauf ruf e 20 durch. Eine Umsetztabelle 42 
ist der Emulationsroutine 16 zugeordnet. Die Umsetztabelle 42 
kann beispielsweise als Hash-Tabelle organisiert sein. Sie 
stellt die Verknupfung zwischen den Ref erenzwerten gemafi den 



WO 99/31584 



PCT/DE98/03484 



16 

Konventionen des Ziel-Betr iebssystems 14 beziehungsweise des 
Anwendungsprogramms 12 her. 

Wenn beispielsweise das Anwendungsprogramm 12 den in der er- 
sten Zeile das Ausschnitts 38 gezeigten Aufruf SYS_get durch- 
fiihrt, um ein Element uw eines abstrakten Datentyps zu erhal- 
ten, setzt die ent sprechende Emulationsroutine 16 diesen Auf- 
ruf in den in der ersten Zeile von Ausschnitt 40 gezeigten 
Systemauf ruf 20 des Ziel-Betriebssys terns 14 um, Der System- 
aufruf 20 liefere als Ergebnis den Referenzwert zw. Dieser 
Wert wird von der Emulationsroutine 16 in der Umset ztabelle 
42 gesucht. Wenn zw nicht gefunden wird, so wahlt die Emula- 
tionsroutine 16 einen neuen Wert uw aus dem Wertebereich des 
Ursprungstyps aus, der noch nicht in der Umset ztabelle 42 
enthalten ist. Das Wertepaar (uw, zw) wird nun in die Umsetz- 
tabelle 42 eingetragen, und der Wert uw des Ursprungstyps 
wird an das Anwendungsprogramm 12 zuriackgegeben . In den mei- 
sten Fallen konnen die Werte des Ursprungstyps als Zahlen in- 
terpretiert werden. Neue Werte lassen sich dann einfach durch 
Hochzahlen erhalten . 

Das Anwendungsprogramm 12 verwendet den erhaltenen Wert uw in 
weiteren Systemauf ruf en als Parameter, Bei einem solchen Auf- 
ruf, der in der letzten Zeile von Ausschnitt 38 gezeigt ist, 
sorgt die Emulationsroutine 16 wiederum fur die er f orderl iche 
Umsetzung, indem der Wert uw in der Umsetztabelle 42 nachge- 
schlagen und durch den Wert zw ersetzt wird. Die Emulations- 
routine 16 leitet dann den Systemauf ruf mit dem Referenzwert 
zw an das Ziel-Betr iebssystem 14 weiter, wie in der letzten 
Zeile von Ausschnitt 40 dargestellt. 

4. Ubergabe von Funktionen ( Funktionsadressen) 

In einigen Fallen werden Funktionen (zum Beispiel Fehlerbe- 
handlungsroutinen) als Parameter bei einem Systemaufruf uber- 
geben. Dies ist beispielsweise bei dem UNIX-Systemauf ruf 
"signal" der Fall, bei dem die ubergebene Funktion als 
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Interrupt-Handler dient. Zur Ubergabe einer Funktion wird 
deren Einsprungadresse (Funktionsadresse) ubergeben. 

In der Regel stimmen die Funkt ionsauf ruf -Konvent ionen des 
ursprunglichen Systems nicht mit denen des Zielsystems 10 
uberein, so daft ein direkter Aufruf einer ursprunglichen 
Funktion durch das Ziel-Betr iebssystem 14 nicht moglich ist. 
In bevorzugten Ausf uhrungsbeispielen der Erfindung ist des- 
halb eines (oder beide) der folgenden Ver f ahren • zur Behand- 
lung von Funkt ionsadressen als Parameter vorgesehen. 

4.1 Dynamische Generierung von Adapter funktionen 

Diese Variante ist in Fig. 5 gezeigt. In einem Ausschnitt 44 
des Anwendungsprogramms 12 wird eine Funktion f deklariert 
und als Parameter eines Systemauf ruf s ubergeben. Die entspre- 
chende Emulationsrout ine 16, von der in Fig. 5 ein Ausschnitt 
46 dargestellt ist, generiert dynamisch den Code fur eine 
Adapterfunktion 48, die gemaft den Konventionen des Zielsy- 
stems 10 aufgerufen werden kann (erste Zeile von Ausschnitt 
4 6) . Die Adresse dieser Adapterfunktion 48 wird dann von der 
Emulationsroutine 16 anstelle der ursprunglichen Funktions- 
adresse an das Ziel-Betr iebssystem 14 ubergeben (letzte Zeile 
von Ausschnitt 46) . 

Die Adapterfunktion 48 ist dazu einger ichtet , etwaige Para- 
meter nach den hier geschilderten Verfahren zu konvertieren 
und schlieftlich die ursprungliche Funktion f mit den konver- 
tierten Parametern aufzurufen. 

In bevorzugten Ausf uhrungsbeispielen ftihren die Emulations- 
routinen 16 Buch darliber, fur welche ursprunglichen Funk- 
tionsadressen bereits Adapterf unktionen generiert wurden. Da- 
durch wird vermieden, daft mehrere Adapter funkt ionen fur ein 
und dieselbe Funktionsadresse erzeugt werden. 
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4.2 Universelle Adapter funktionen 

Bei dieser in Fig. 6 veranschaulichten Variante ist minde- 
stens eine universelle Adapter funktion 50 vorgesehen, die 
nach den Konventionen des Ziel-Betriebssystems 14 aufgerufen 
werden kann und als "Sprungbrett" fur mehrere vom Anwendungs- 
prograram 12 ubergebene Funktionen dient. Eine Auf ruf tabelle 
52 dient zum Eintragen und Zuordnen der let ztgenannten Funk- 
tionen. 

Wenn bei einem Systemauf ruf des Anwendungsprogramms 12 eine 
Funktionsadresse als Parameter ubergeben wird (letzte Zeile 
von Ausschnitt 44), dann tragt die Emulationsroutine 16, die 
diesen Aufruf 18 abfangt, die Funktionsadresse unter einem 
entsprechenden Index in die Auf ruf tabelle 52 ein. Dem Ziel- 
Betriebssystem 14 wird von der Emulationsroutine 16 als Funk- 
tionsadresse die Adresse der universellen Adapterfunktion 50 
ubergeben {Systemauf ruf in Ausschnitt 4 6) . Wenn spater das 
Ziel-Betriebssystem 14 die universelle Adapterfunktion 50 
aufruft, so konvertiert letztere eventuelle Parameter, ladt 
die urspriingliche Funktionsadresse aus der Auf ruf tabelle 52 
und ruft diese Funktion auf. 

Das eben beschriebene Verfahren ist besonders fur den UNIX- 
Systemaufruf "signal" oder vergleichbare Systemauf ruf e in 
anderen Betriebssystemen geeignet, weil die Auf ruf tabelle 52 
dann einfach als ein Array mit dem Signal als Index organi- 
siert werden kann, wie dies in Fig. 6 gezeigt ist. 

5 . Dateien 

Inhalte von Dateien haben unter Umstanden auf dem urspriing- 
lichen System und auf dem Zielsystem 10 unterschiedliche For 
mate (zum Beispiel hinsichtlich der Darstellung von binar ko 
dierten numerischen Werten oder hinsichtlich des verwendeten 
Zeichenkodes ) . In den hier beschriebenen Ausf uhrungsbeispie- 
len werden applikationsspezif ische Dateien nicht umgesetzt. 
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Systemdateien (also Dateien, deren Struktur vom Betriebs- 
system bestimmt wird) , werden dagegen sowohl in einer Fassung 
fur das Anwendungsprogramm 12 als auch in einer damit syn- 
chronisierten Fassung fur das Ziel-Betriebssystem 14 bereit- 
gestellt. Systemdateien (zum Beispiel die Datei "terminfo" 
bei UNIX) werden daran erkannt, daft sie einen vom Betriebs- 
system festgelegten Datei- und/oder Pfadnamen aufweisen. Die- 
ser Name dient als Ref erenzwert , der einen Zugriff auf die 
eigentliche Datei ermoglicht. 

In dem hier beschriebenen Ausf uhrungsbeispiel liegen auf dem 
Zielsystem 10 Kopien der Systemdateien des Ursprungssystems 
vor. Diese sind auf dem Zielsystem 10 in der Regel nicht 
unter dem gleichen Pfad wie auf dem ursprunglichen System 
verfiigbar, da sich dort schon die ent sprechenden zielsystem- 
spezifischen Dateien befinden. 

Bei der Umsetzung eines Sys temauf ruf s des Anwendungsprogramms 
12, der auf eine Datei zugreift (zum Beispiel der Auf ruf 
"open" bei UNIX) iiberpruft die betreffende Emulationsroutine 
16 anhand des Pfadnamens, ob es sich urn einen Zugriff auf 
eine Systemdatei handelt. Falls ja, dann wird der angegebene 
Pfad durch den der Emulationsroutine 16 bekannten Pfadnamen 
zu der entsprechenden Kopie der Datei aus dem urspriinglichen 
System ersetzt. 

Die aus dem urspriinglichen System ubernommenen Dateien und 
die Systemdateien des Zielsystems 10 konnen auf unterschied- 
liche Weise synchronisiert werden. Beispielsweise kann ein 
Daemon vorgesehen sein, der die Dateien periodisch jeweils 
paarweise abgleicht. Ferner konnen die Emulationsroutinen 16 
so ausgestaltet sein, daJJ sie bei jedem schreibenden Zugriff 
auf eine Systemdatei beide Fassungen aktualisieren . Wenn eine 
Systemdatei mit Hilfe eines speziellen Compilers aus einem 
Quelltext generiert wird (wie zum Beispiel die UNIX-System- 
datei "terminfo" mit dem Compiler "tic"), dann kann neben dem 
Compiler des Ziel-Betr iebssystems 14 eine Kopie des entspre- 
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chenden Compilers aus dem ursprunglichen System gestartet 
werden, urn beide Varianten der Systemdatei zu generieren. 
Schliefilich ist es auch mdglich, einen modif izierten Compiler 
einzusetzen, der stets beide Versionen erzeugt. 

5 

In Ausfuhrungsalternativen der Erfindung sind nicht alle der 
oben beschriebenen Konvert ierungsver f ahren implementiert . Als 
besonders wichtig wird gegenwartig die Behandlung von ab- 
strakten Datentypen, Zeigern auf Funktionen und Systemdateien 
10 angesehen. 
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Patentanspruche 

1. Verfahren zum Umsetzen eines Systemauf ruf s fur ein 
Ursprungs-Betriebssystem in einen Systemauf ruf (20) fur ein 
Ziel-Betriebssystem (14), bei dem: 

a) eine Emulationsrout ine (16) aufgerufen wird, 

b) die Emulationsroutine (16) eine Ref erenzstruktur , die 
einen Referenzwert und zumindest ein ref erenziertes Element 
aufweist, umsetzt, indem zumindest der Referenzwert umgesetzt 
wird, und 

c) die Emulationsroutine (16) den Systemaufruf (20) fur das 
Ziel-Betriebssystem (14) durchf iihrt . 



2. Verfahren nach Anspruch 1, 

dadurch gekennzeichnet, daft die Emulationsrou- 
tine (16) iiberwiegend, vorzugsweise im wesentlichen aus- 
schlieftlich, Umsetzungsf unktionen ausf iihrt . 

3. Verfahren nach Anspruch 1 oder 2, 

dadurch gekennzeichnet, daft in Schritt b) f erner 
das mindestens eine ref erenzierte Element zumindest teilweise 
umgesetzt wird. 

4. Verfahren nach Anspruch 1 oder 2, 

5 dadurch gekennzeichnet, daft der Referenzwert ein 
nicht weiter von der Emulationsroutine (16) interpret ierbares 
Element ref erenziert . 



5. Verfahren nach einem der Anspruche 1 bis 4, 

0 dadurch gekennzeichnet, daft die 

Emulationsroutine (16) zum Umsetzen des Ref erenzwertes auf 
eine Umsetztabelle (42) zugreift, in der je ein Referenzwert 
in dem Systemaufruf fur das Ursprungs-Betriebssystem und ein 
Referenzwert in dem Systemaufruf (20) fur das Ziel- 

5 Betriebssystem (14) einander zugeordnet sind. 
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6. Verfahren nach Anspruch 5, 

dadurch gekennzeichnet, daft uberpruf t wird, ob 
ein Referenzwert, der als Ergebnis eines Systemauf ruf s (20) 
fur das Ziel-Betr iebssys tem (14) erhalten wurde, in der Um- 
setztabelle (42) enthalten ist, und daft, wenn dies nicht der 
Fall ist, diesem Referenzwert in der Umsetztabelle (42) ein 
neuer Referenzwert, der gemaft den Konventionen des Ursprungs- 
Betriebssystems gebildet wurde, zugeordnet wird.. 

7. Verfahren nach einem der Anspruche 1 bis 4, 
dadurch gekennzeichnet, daft das ref erenzierte 
Element eine Funktion ist, und daft die Emulationsroutine (16) 
bei der Umsetzung einen neuen Referenzwert erzeugt, der auf 
eine Adapter funktion (48, 50) verweist. 

8. Verfahren nach Anspruch 7, 

dadurch gekennzeichnet, daft die Adapter funktion 
(48) bei der Umsetzung in Abhangigkeit von der durch den 
urspriinglichen Referenzwert ref erenzierten Funktion gebildet 
wird . 

9. Verfahren nach Anspruch 7, 

dadurch gekennzeichnet, daft der neue 
Referenzwert auf eine universelle Adapter funktion (50) 
verweist, die dazu eingerichtet ist, auf eine Auf ruf tabelle 
(52) zuzugreifen, urn die durch den urspriinglichen . 
Referenzwert ref erenzierte Funktion zu bestiminen. 

10. Verfahren nach einem der Anspruche 1 bis 4, 
dadurch gekennzeichnet, daft das ref erenzierte 
Element eine erste Systemdatei gemaft den Konventionen entwe- 
der des Ursprungs-Betriebssystems oder des Ziel-Betriebs- 
systems (14) ist, und daft der Referenzwert auf eine zweite 
Systemdatei umgesetzt wird, die mit der ersten Systemdatei 
synchronisiert ist, aber gemaft den Konventionen des je 
anderen Betr iebssystems aufgebaut ist. 
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11. Verfahren nach einem der Anspruche 1 bis 3, 
dadurch gekennzeichnet, daft das ref erenzierte 
Element ein Element eines Produktdatentyps und/oder eine 
verkettete Datenstruktur ist, und daft bei der Umsetzung das 
referenzierte Element, soweit erf order lich, feld- und/oder 
elementweise kopiert und umgesetzt wird. 

12. Verfahren nach einem der Anspruche 1 bis 3, 

da dure h gekennzeichnet, daft das referenzierte 
Element eine von der Emulationsroutine (16) interpretierbare 
Bedeutung hat, und daft diese Bedeutung bei der Umsetzung des 
referenzierten Elements im wesentlichen erhalten wird. 

13. Verfahren nach Anspruch 12, 

dadurch gekennzeichnet, daft das referenzierte 
Element ein Element eines Datumstyps und/oder eines Zeittyps 
und/oder eines Kontexttyps und/oder eines Zeichenkettentyps 
und/oder eines zumindest einen der genannten Typen als Kompo- 
nente aufweisenden Produkttyps ist. 
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FIG 2 
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struct { . . . } s; 
SYS . . . (&s) ; 



> 



struct 


(...) si; 


si . X - 


cvt ( s . x ) ; 


• • • 

SYS_. . 


. Usl) ; 


S . X = 

• • • 


recvt ( s 1 . x) ; 
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struct s 



struct si 
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uw = SYS_get {...); 
* *t 

SYS ... (uw, . . . ) ; 
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FIG 4 



zw = SYS_get (...); 

SYS • ♦ • I ZW J m m • ) J 



1 


zw 
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void f (...) ; 
SYS . . . (&f ) ; 
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fa = gen_adapt ( &f ) 
SYS ... (fa) ; 
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'■void adapt ( 
i { ... 
A — ► f (...) ; 
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FIG 5 
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void f ( . . 


. ) ; 




SYS . . . (SIG, 


&f ) ; 
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Tabelle Tab 
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♦ SIG 
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SYS_. . . (SIG, adapt) ; 
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void^ adapt (sig, . . . ) 
{ fa = Tab [ sig) ; 

• • « 

( * f a) (sig, . . . ) ; 
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